Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-cat-ftpsec-02.txt < prev next >

Wrap

Text File | 1993-07-08 | 38KB | 929 lines

Network Working Group Internet Engineering Task Force Internet-Draft Common Authentication Technology Working Group Updates: RFC 959 S. J. Lunt Bellcore July 1993 FTP Security Extensions Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Please send comments to the <ftp-wg@tgv.com> mailing list. 1. Description This document defines extensions to the FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication Type), ADAT (Authentication Data), MIC (Integrity Protected Command), ENC (Privacy Protected Command), and PROT (Data Channel Protection Level). A new class of reply types (6yz) is also introduced for protected replies. Expires: January 31, 1994 [Page 1] Internet-Draft FTP Security Extensions July 1993 None of the above commands are required to be implemented, but each is dependent on the other (except ENC, which is optional). Note that this specification is compatible with RFC 959. 2. Motivation The File Transfer Protocol (FTP) currently defined in RFC 959 and in place on the Internet uses usernames and passwords passed in cleartext to authenticate clients to servers (via the USER and PASS commands). Except for services such as 'anonymous' FTP archives, this represents a security risk whereby passwords can be stolen through monitoring of local and wide-area networks. This either aids potential attackers through password exposure and/or limits accessibility of files to remote users who can or will not accept the inherent security risk. Aside from the problem of authenticating users in a secure manner, there is also the problem of protecting sensitive data and/or verifying its integrity. An attacker may be able to access valuable or sensitive data merely by monitoring a network, or through active means may be able to delete or modify the data being transferred so as to corrupt its integrity. An active attacker may also initiate spurious file transfers to and from a site of the attacker's choice, and may invoke other commands on the server. FTP does not currently have any provision for the encryption or verification of the authenticity of commands, replies, or transferred data. Note that these security services have value even to anonymous file access. Current practice for sending files securely is generally either: 1. via FTP of files pre-encrypted under keys which are manually distributed, 2. via electronic mail containing an encoding of a file encrypted under keys which are manually distributed, 3. via a PEM message, or 4. via the rcp command enhanced to use Kerberos. None of these means could be considered even a de facto standard, and none are truly interactive. A need exists to securely transfer files using FTP in a secure manner which is supported within the FTP protocol in a consistent manner and which takes advantage of existing security infrastructure and technology. Extensions are necessary to the FTP specification if these security services are to be introduced into the protocol in an interoperable way. Expires: January 31, 1994 [Page 2] Internet-Draft FTP Security Extensions July 1993 Although the FTP control connection follows the Telnet protocol, and Telnet has defined an authentication and encryption option [5], RFC 1123 [4] explicitly forbids the use of Telnet option negotiation over the control connection (other than Synch and IP). Also, the Telnet authentication and encryption option does not provide for integrity protection only (without confidentiality), and does not address the protection of the data channel. 3. New FTP Commands The following commands are optional, but dependent on each other. They are extensions to the FTP Access Control Commands. AUTHENTICATION TYPE (AUTH) The argument field is a Telnet string identifying a supported authentication mechanism. The command represents a request to perform an authentication protocol exchange based on an authentication mechanism identified by the argument. Currently, only KERBEROS_V4 and GSSAPI are defined. If the server accepts an authentication type with reply code 334, then the client must next initiate an authentication exchange (via the ADAT command) based on that authentication type. The goal of the authentication exchange is to strongly authenticate the user to the server, and to establish a security context [3] under which protection of the control and data channels may be performed. If the server replies with a 234 code, then the authentication type is accepted, and no ADAT commands are required. This is useful to indicate to the server that the password to be sent in a subsequent PASS command is to be interpreted differently than normal, as in the case of smart cards or other non-disclosing password systems. Challenge information intended for human interpretation may be contained in the reply. Such information may also be conveyed in the text of the reply to the USER command. If the server rejects a type (reply code 504), or any ADAT command fails, then the client may try another authentication type by issuing another AUTH command, or may continue by sending USER and PASS commands. Thus, the client should request authentication types in decreasing order of preference (i.e., strength). The server will reject (with a 503 reply code) any AUTH or ADAT commands sent after an authentication protocol successfully completes. The client should not require the server to support the AUTH command or any particular authentication type. If either the server does not support the AUTH command (reply code 500), or the client and server cannot agree on an authentication type, or no Expires: January 31, 1994 [Page 3] Internet-Draft FTP Security Extensions July 1993 authentication exchange succeeds, then the default USER and PASS commands must be performed. The AUTH command will normally be the first command transmitted by the user after the control connections are made, generally before the USER command. However, some authentication protocols may require prior knowledge of the remote user name (e.g., some challenge/response systems). In this case, the USER command may be sent in advance of the AUTH command. Some servers will require that authentication be performed before certain commands (including USER) will be accepted. In this case, a 530 reply will be sent indicating that an authentication exchange is required. AUTHENTICATION DATA (ADAT) The argument field is a Telnet string representing a base 64 encoded authentication data (see Section 5, "Base 64 Encoding"). The data is specific to the authentication protocol specified by a previous AUTH command. The ADAT command, and the associated replies, allow the client and server to conduct an arbitrary authentication protocol. The client will send authentication data to the server via the ADAT command, and the server will send authentication back to the client by including "ADAT=string" in the reply, where string is also a Telnet string representing base 64 encoded authentication data. The server will reply 501 if the string could not be base 64 decoded. If the server sends a 535 reply, then the authentication data could not be successfully processed, and the client has not been authenticated. The client may either try another authentication type by sending another AUTH command, or may send USER and PASS commands. The server will reply 503 if no AUTH command was previously accepted. If the server sends a 335 reply, then the authentication data was successfully processed, but more authentication data is necessary to complete the authentication process. In this case, the server must include encoded authentication data in the reply. The client must process this returned data and then issue another ADAT command. If the server sends a 235 reply, optionally including encoded authentication data, then the server considers the client authenticated. The client must process any authentication data present in the reply. Appendix I defines the actual protocol for KERBEROS_V4. Appendix Expires: January 31, 1994 [Page 4] Internet-Draft FTP Security Extensions July 1993 II defines the actual protocol for GSSAPI. If an authentication exchange succeeds, then the client's identity has been authenticated but not yet authorized. The client must next invoke the USER command to identify to the server the account (file system) for which access is requested. If the USER command results in a 231 reply, then the client is authorized, and no password is required. However, the client must then send the PASS command to actually log the user in (the actual password is ignored and should be a dummy value). If the USER command results in a 333 reply, then the user was not authorized without a password, and a password must be sent with the PASS command. In this case, it is recommended that the PASS command be ENC protected. Additional USER or PASS commands may be sent after success of an ADAT command. Once the client is successfully authenticated via AUTH and ADAT commands, the rest of the data over the control channel (commands and replies) must be protected, either with integrity (by a cryptographic checksum) via the MIC command, or with confidentiality (by encryption) via the ENC command. (Also see Section 4 on protected replies.) These two commands may be arbitrarily intermixed. It is up to the client to decide which of MIC and ENC commands to use, and it is up to the server when to accept either. The server will return a 502 reply to any other command. The server will return a 500 reply to a MIC or ENC command if no ADAT command succeeded. Commands sent via the Telnet out-of-band signal must also be protected. That is, if the client sends the Telnet "Interrupt Process" (IP) signal followed by the Telnet "Synch" signal, then the command sent to the server immediately afterwards must also protected. A requirement of all specifications for authentication exchanges based on new authentication types is that they convey to the caller whether encryption is supported on the resultant security context, since it is not a requirement that the ENC command, 632 protected replies, or the Private protection level be supported. It is also strongly suggested that per message protection services supported by each mechanism perform message replay and out-of- sequence detection, since no provision for these services is explicitly made within this specification. Since no explicit provision is made in this specification for the negotiation of alternate mechanisms for performing per message protection services, implementors should instead utilize the token exchange for this purpose. Expires: January 31, 1994 [Page 5] Internet-Draft FTP Security Extensions July 1993 INTEGRITY PROTECTED COMMAND (MIC) The argument field is a Telnet string consisting of a base 64 encoded "safe" message produced by an authentication mechanism specific message integrity procedure. The server will decode the received string, verify its integrity via the authentication mechanism specific message integrity procedure, and upon success, interpret the resultant string as an FTP command. The user- process need not include the Telnet end-of-line code within the encoded command. The server will return a 501 reply if the argument could not be properly base 64 decoded. The server will return a 535 reply to any MIC command which fails checksum, replay, sequencing, or other applicable security checks. The server may return a 402 reply to a MIC command if it is not willing to accept MIC commands and instead will accept ENC commands only. In this case, the client should retry the enclosed command under ENC protection. The three replies defined above must themselves be protected. There are no other direct replies from MIC or ENC commands; the resultant FTP command will generate its own replies. In environments where the native character set is not ASCII, the client must translate the encapsulated command to ASCII before passing it to the protection routine, and the server must translate the encapsulated command from ASCII after passing the token to the protection routine. PRIVACY PROTECTED COMMAND (ENC) The argument field is a Telnet string consisting of a base 64 encoded "private" message produced by an authentication mechanism specific message confidentiality procedure. The server will decode the received string, verify its integrity and confidentiality via the authentication mechanism specific message confidentiality procedure, and upon success, interpret the resultant string as an FTP command. It is strongly recommended that PASS commands be sent under ENC protection, when possible. The server will return a 501 reply if the argument could not be properly base 64 decoded. Expires: January 31, 1994 [Page 6] Internet-Draft FTP Security Extensions July 1993 The server will return a 535 reply to any ENC command which cannot be properly decrypted, or fails checksum, replay, sequencing, or other applicable security checks. The server will return a 402 reply if it does not support the ENC command. In this case, the client should retry the enclosed command under MIC protection. The three replies defined above must themselves be protected. DATA CHANNEL PROTECTION LEVEL (PROT) The argument is a single Telnet character code specifying the data channel protection level. The PROT command will be rejected and the server will reply 504 if no previous ADAT command succeeded, or the specified protection level is not supported. Upon success, a 200 reply will be sent by the server, indicating that the new protection level is now in effect. The following codes are assigned for protection levels: C - Clear S - Safe P - Private The default protection level is Clear. The Safe protection level is required to be implemented by all authentication types which exchange ADAT commands, but the Private protection level is optional. When using the Safe protection level, all data sent over the data channel is to be integrity protected by cryptographic checksum. When using the Private protection level, all data sent over the data channel is to be privacy protected by encryption. The sender will apply protection services after all data transformations associated with the current representation type, file structure, and transfer mode have been performed. The data sent over the data channel is, for the purposes of data protection, to be treated as a byte stream. An authentication mechanism specific data protection procedure will be employed by the sender to protect this byte stream. The procedure should process a buffer of bytes at a time, and send the result as a stream of bytes, prepending each transferred buffer with a two byte length field (most significant byte first). Thus, a minimal implementation must be able to handle a buffer length of 65,536 bytes. (Implementors must ensure that they encrypt a maximum cleartext buffer somewhat smaller than this such that the resultant ciphertext buffer is assured to be no greater than this Expires: January 31, 1994 [Page 7] Internet-Draft FTP Security Extensions July 1993 maximum.) The receiver will read the two byte length field, and then read that number of bytes of protected data, passing the buffer to an authentication mechanism specific data protection procedure. Further buffers will be similarly read and processed until all bytes are sent. Any transformations associated with the current representation type, file structure, and transfer mode would then be performed by the receiver on the resultant data. When using block transfer mode, the sender's (cleartext) buffer size is independent of the block size. Under the Clear protection level (i.e., as currently defined in RFC 959), and when in stream mode, the sender indicates end of file by closing the data connection. This is inherently unreliable, since the receiver cannot determine whether the connection was closed prematurely. Transferring files under the Safe or Private protection level allows the sender to convey a positive indication of end of file by sending a protected buffer which contains zero bytes of cleartext data. Upon receipt of such a zero length cleartext buffer, the recipient should close the data connection (without further reading from the connection) and consider the file transfer complete. If the connection is closed before such a buffer is received, then the file transfer should be aborted, and the user should be alerted. If the server was the recipient, then it should send a 535 reply in this case. If any data protection services fail at any time during data transfer at the server end, the server will send a 535 reply. The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE command if the current protection level is not at the level dictated by the server's security requirements for the particular file transfer. 4. New FTP Replies All replies after a successful ADAT command must be protected. A new reply type is introduced for this purpose, indicated by a sixth value for the first digit of the reply code: 6yz Protected reply The text of this reply is to be decoded and interpreted as an FTP reply (if such decoding is successful). If the reply code is 631, then the text of the reply is integrity protected in the same manner as MIC commands. If the reply code is 632, then the text of the reply is privacy protected in the same manner as ENC commands. The server need not include the Telnet end-of-line code within the encoded reply. All replies must be protected once an ADAT command succeeds. The server may send a protected reply only Expires: January 31, 1994 [Page 8] Internet-Draft FTP Security Extensions July 1993 if a previous ADAT command succeeded. The security policy of the server will dictate when 631 or 632 replies are to be used. As a general rule, the server should send a 631 reply to a MIC command, and a 632 reply to an ENC command. The server must not send 632 replies if the client does not support encryption (this should be indicated by the security context). If, upon context establishment, it is not known whether the client supports encryption, then the server may send a 632 reply only if client support of encryption has been indicated implicitly by means of the client issuing an ENC command or a PROT P command. Multi-line replies are handled as follows. If the server sends a protected reply in which the decoded reply has a hyphen ("-") immediately following the reply code, then the server will send the rest of the lines of text of the multi-line reply each protected and base 64 encoded as was the first line, and each followed by the Telnet end-of-line code. The last line of the multi-line reply will be that line which when decoded by the receiver begins with the initial reply code followed by a space. For consistency with RFC 959 replies, each line of a protected multi-line replies should begin with either a 631 or 632 code followed by a hyphen or, on the last line, a space. However, note that it is the format of the decoded reply, and not the enclosing protected reply, that indicates a multi-line reply. The following is an example showing the format of a four line multi-line reply: 631-<base64string> 631-<base64string> 631-<base64string> 631 <base64string> If the server for some reason cannot encode the reply, then the unprotected reply will be sent instead. However, the client should ignore the reply code of any cleartext reply sent after the success of an ADAT command, and instead simply display the text of the reply to the user. 5. Base 64 Encoding Base 64 encoding is the same as the Printable Encoding described in Section 4.3.2.4 of [2] and is defined as follows. Proceeding from left to right, the bit string resulting from the mechanism specific protection routine is encoded into characters which are universally representable at all sites, though not Expires: January 31, 1994 [Page 9] Internet-Draft FTP Security Extensions July 1993 necessarily with the same bit patterns (e.g., although the character "E" is represented in an ASCII-based system as hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the local significance of the two representations is equivalent). A 64-character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure. The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group output from the authentication mechanism specific message protection procedure, each 6-bit group is used as an index into an array of 64 printable characters, namely "[A-Z][a- z][0-9]+/". The character referenced by the index is placed in the output string. These characters are selected so as to be universally representable, and the set excludes characters with particular significance to Telnet (e.g., "<CR>", "<LF>", IAC). Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Implementors should keep in mind that the base 64 encodings in ADAT, MIC, and ENC commands, and in 631 and 632 replies, may be arbitrarily long. Thus, the entire line must be read before it can be processed. Several successive reads on the control channel may be necessary. It is not appropriate to for a server to reject a command containing a base 64 encoding simply because it is too long (assuming that the decoding is otherwise well formed in the context in which it was sent). Case should not be ignored when reading commands and replies containing base 64 encodings. Expires: January 31, 1994 [Page 10] Internet-Draft FTP Security Extensions July 1993 6. Command Summary The following is a summary of the commands described above: AUTH <SP> <auth-type> <CRLF> ADAT <SP> <base64string> <CRLF> MIC <SP> <base64string> <CRLF> ENC <SP> <base64string> <CRLF> PROT <SP> <protection-level> <CRLF> The syntax of the above argument fields (using BNF notation where applicable) is: <auth-type> ::= <string> <string> ::= <char> | <char><string> <char> ::= any of the 128 ASCII characters except <CR> and <LF> <protection-level> ::= C | S | P <base64string> ::= <quads> | <quads><terminal> <quads> ::= <quad> | <quad><quads> <quad> ::= <base64char><base64char><base64char><base64char> <base64char> ::= ASCII A through Z | ASCII a through z | ASCII 0 through 9 | ASCII + | ASCII / <terminal> ::= <base64char><terminal1><pad><pad> | <base64char><base64char><terminal2><pad> <terminal1> ::= A | Q | g | w <terminal2> ::= A | E | I | M | Q | U | Y | c | g | k | o | s | w | 0 | 4 | 8 <pad> ::= ASCII = The following lists the various reply codes for each new command: AUTH 234 334 500, 501, 503, 504, 421 ADAT 235 335 500, 501, 503, 535, 421 MIC 402 500, 501, 535, 421 ENC 402 500, 501, 535, 421 PROT Expires: January 31, 1994 [Page 11] Internet-Draft FTP Security Extensions July 1993 200 500, 501, 504, 421, 530 The following are additional reply codes for existing commands (502 is the only reply for all commands except ENC and MIC once an ADAT command succeeds): USER 231 333 STOR 534, 535 STOU 534, 535 RETR 534, 535 LIST 534, 535 NLST 534, 535 APPE 534, 535 The following is the syntax for protected replies: <code> <SP> <base64string> <CRLF> <code> ::= 631 | 632 Lines of the following form may preceed this in the case of a multi- line protected reply: <code> <hyphen> <base64string> <CRLF> <hyphen> ::= ASCII - 7. References [1] Reynolds, Joyce, and Postel, Jon, "File Transfer Protocol (FTP)", RFC 959, ISI, October 1985. [2] Linn, John, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [3] Linn, John, "Generic Security Service API (GSSAPI)", Internet Draft, November 1992. [4] Braden, R., "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [5] Borman, D., "Telnet Authentication and Encryption Option", Expires: January 31, 1994 [Page 12] Internet-Draft FTP Security Extensions July 1993 Internet Draft, Cray Research, Inc, April 1993. Security Considerations Third party file transfers cannot be secured using these extensions, since a security context cannot be established between two servers using these facilities (no control connection exists between server over which to pass ADAT tokens). Further work in this area is deferred. APPENDIX I: SPECIFICATION UNDER KERBEROS VERSION 4 The authentication type (for the AUTH command) associated with Kerberos Version 4 is KERBEROS_V4. If the server supports KERBEROS_V4, it will respond with a 334 reply code indicating that an ADAT command is expected next. The client should retrieve a ticket for the Kerberos principal "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name of "ftp", an instance equal to the canonical host name of the server with all letters in lower case (as returned by krb_get_phost(3)), the server's realm name (as returned by krb_realmofhost(3)), and an arbitrary checksum. The ticket must then be base 64 encoded and sent as the argument to an ADAT command. The server must base 64 decode the argument to the ADAT command and pass the result to krb_rd_req(3). The server must add one to the checksum from the authenticator and sign it using krb_mk_safe(3), then base 64 encode the result. Upon success, the server must reply to the client with a 235 code and include "ADAT=base64string" in the text of the reply. Upon failure, the server will reply 535. Upon receipt of the 235 reply from the server, the client must parse the text of the reply for the base 64 encoded data, decode it, and pass the result to krb_rd_safe(3). The client should consider the server authenticated if the resultant checksum is equal to one plus the value previously sent. The procedure associated with integrity protected MIC commands, replies, and Safe file transfers is: krb_mk_safe(3) for the sender krb_rd_safe(3) for the receiver The procedure associated with privacy protected ENC commands, replies, and Private file transfers is: krb_mk_priv(3) for the sender krb_rd_priv(3) for the receiver Expires: January 31, 1994 [Page 13] Internet-Draft FTP Security Extensions July 1993 Note that this specification for KERBEROS_V4 contains no provision for negotiating alternate means for integrity and confidentiality routines. Note also that the ADAT exchange does not convey whether the peer supports confidentiality services. APPENDIX II: SPECIFICATION UNDER THE GSSAPI The authentication type (for the AUTH command) associated with all mechanisms employing the GSSAPI is GSSAPI. If the server supports an authentication mechanism employing the GSSAPI, it will respond with a 334 reply code indicating that an ADAT command is expected next. The client should begin the authentication exchange by calling GSS_Init_Sec_Context, passing in NULL for claimant_cred_handle to get the default credentials for the user (this is to avoid dependencies on names for particular mechanisms), 0 for input_context_handle (initially), NULL for mech_type (indicating "use default mechanism type"), and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of NULL and input_name_string of "SERVICE:ftp@hostname" where "hostname" is the fully qualified host name of the server with all letters in lower case. The output_token must then be base 64 encoded and sent to the server as the argument to an ADAT command. If GSS_Init_Sec_Context returns GSS_CONTINUE_NEEDED, then the client should expect a token to be returned in the reply to the ADAT command. This token should subsequently be passed to another call to GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns no output_token, then the reply code from the server for the previous ADAT command should have been 235. If GSS_Init_Sec_Context returns GSS_COMPLETE, then no further tokens should be expected from the server, and the client should consider the server authenticated. The server must base 64 decode the argument to the ADAT command and pass the resultant token to GSS_Accept_Sec_Context as input_token, setting acceptor_cred_handle to NULL (for "use default credentials"), and 0 for input_context_handle (initially). If an output_token is returned, it should be base 64 encoded and returned to the client by including "ADAT=base64string" in the text of the reply. If GSS_Accept_Sec_Context returns GSS_COMPLETE, the reply code should be 235, and the server should consider the client authenticated. If GSS_Accept_Sec_Context returns GSS_CONTINUE_NEEDED, the reply code should be 335. Otherwise, the reply code should be 535, and the text of the reply should contain a descriptive error message. The procedure associated with integrity protected MIC commands, replies, and Safe file transfers is: GSS_Safe for the sender GSS_Verify for the receiver Expires: January 31, 1994 [Page 14] Internet-Draft FTP Security Extensions July 1993 The procedure associated with privacy protected ENC commands, replies, and Private file transfers is: GSS_Seal for the sender GSS_Unseal for the receiver Both the client and server should inspect the value of conf_avail to determine whether the peer supports confidentiality services. Author's Address: Steven J. Lunt Bellcore RRC-1L213 444 Hoes Lane Piscataway, NJ 08854 Phone: (908) 699-4244 EMail: lunt@bellcore.com Mailing List: ftp-wg@tgv.com Chair's Address: The working group can be contacted via the current chair: Sam Sjogren TGV, Inc. 603 Mission St. Santa Cruz, CA 95060 Phone: (408) 427-4366 EMail: sjogren@tgv.com Author's Notes: This is implemented and working for Kerberos V4 on SunOS 4.1.2 using SunOS source for ftp and ftpd, and also the BSD Reno source for ftp and ftpd. YET TO BE DONE: 1. Determine a suitably general targ_name for GSSAPI. 2. Implementation using GSSAPI. 3. The client may fail when processing the ADAT data from a 235 reply, in which case the server thinks things are OK, but the client thinks otherwise. Unclear how to proceed at that point, Expires: January 31, 1994 [Page 15] Internet-Draft FTP Security Extensions July 1993 other than to drop the connection. 4. New state diagrams might need to be drawn for how the AUTH, ADAT, USER, and PASS commands now flow. 5. It would be desirable to make use of the rcmd principal in Kerberos V4, but there may be some environments where the ftp server needs to run in a chroot'ed environment. Thus, the ftp principal was specified. There should be some way to make use of the rcmd principal if there is no ftp principal at the server site. Expires: January 31, 1994 [Page 16]